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Abstract 

The Windows Vista operating system implements an interesting 
model of multi-level integrity. We observe that in this model, 
trusted code can be blamed for any information-flow attack; thus, 
it is possible to eliminate such attacks by static analysis of trusted 
code. We formalize this model by designing a type system that can 
efficiently enforce data-flow integrity on Windows Vista. Type- 
checking guarantees that objects whose contents are statically 
trusted never contain untrusted values, regardless of what untrusted 
code runs in the environment. Some of Windows Vista's runtime 
access checks are necessary for soundness; others are redundant 
and can be optimized away. 

Categories and Subject Descriptors D.4.6 [Operating Systems]: 
Security and Protection — Access controls, Information flow con- 
trols, Verification; D.2.4 [Software Engineering]: Program Verif- 
ication — Correctness proofs; F.3.1 [Logics and Meanings of Pro- 
grams]: Specifying and Verifying and Reasoning about Programs — 
Specification techniques, Invariants, Mechanical verification 

General Terms Security, Verification, Languages, Theory 

Keywords dynamic access control, data-flow integrity, hybrid 
type system, explicit substitution 

1. Introduction 

Commercial operating systems are seldom designed to prevent 
information-flow attacks. Not surprisingly, such attacks are the 
source of many serious security problems in these systems 144-1 . 
Microsoft's Windows Vista operating system implements an in- 
tegrity model that can potentially prevent such attacks. In some 
ways, this model resembles other, classical models of multi-level 
integrity j9j — every process and objecQ is tagged with an integrity 
label, the labels are ordered by levels of trust, and access control 
is enforced across trust boundaries. In other ways, it is radically 
different. While Windows Vista's access control prevents low- 
integrity processes from writing to high-integrity objects, it does 
not prevent high-integrity processes from reading low-integrity 
objects. Further, Windows Vista's integrity labels are dynamic — 
labels of processes and objects can change at runtime. This model 



1 In this context, an object may be a file, a channel, a memory location, or 
indeed any reference to data or executable code. 
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allows processes at different trust levels to communicate, and al- 
lows dynamic access control. At the same time, it admits various 
information-flow attacks. Fortunately, it turns out that such attacks 
require the participation of trusted processes, and can be eliminated 
by code analysis. 

In this paper, we provide a formalization of Windows Vista's in- 
tegrity model. In particular, we specify an information-flow prop- 
erty called data-flow integrity (DFI), and present a static type sys- 
tem that can enforce DFI on Windows Vista. Roughly, DFI prevents 
any flow of data from the environment to objects whose contents 
are trusted. Our type system relies on Windows Vista's runtime ac- 
cess checks for soundness. The key idea in the type system is to 
maintain a static lower-bound label S for each object. While the 
dynamic label of an object can change at runtime, the type system 
ensures that it never goes below S, and the object never contains a 
value that flows from a label lower than S. The label S is declared 
by the programmer. Typechecking requires no other annotations, 
and can be mechanized by an efficient algorithm. 

By design, DFI does not prevent implicit flows 1 1 81 . Thus DFI 
is weaker than noninterference 1231 . Unfortunately, it is difficult 
to enforce noninterference on a commercial operating system such 
as Windows Vista. Implicit flows abound in such systems. Such 
flows arise out of frequent, necessary interactions between trusted 
code and the environment. They also arise out of covert control 
channels which, given the scope of such systems, are impossible 
to model sufficiently. Instead, DFI focuses on explicit flows 1181 . 
This focus buys a reasonable compromise — DFI prevents a definite 
class of attacks, and can be enforced efficiently on Windows Vista. 
Several successful tools for malware detection follow this approach 
1121 1521 1471 1491 [T6l 1371 , and a similar approach guides the design 
of some recent operating systems B 1 91 1571 . 

Our definition of DFI is dual to standard definitions of secrecy 
based on explicit flows — while secrecy prevents sensitive values 
from flowing to the environment, DFI prevents the flow of values 
from the environment to sensitive objects. Since there is a rich liter- 
ature on type-based and logic-based analysis for such definitions of 
secrecy 11 ll [3l[48l|l3|, it makes sense to adapt this analysis for DFI. 
Such an adaptation works, but requires some care. Unlike secrecy, 
DFI cannot be enforced without runtime checks. In particular, ac- 
cess checks play a crucial role by restricting untrusted processes 
that may run in the environment. Further, while secrecy prevents 
any flow of high-security information to the environment, DFI al- 
lows certain flows of low-security information from the environ- 
ment. We need to introduce new technical devices for this purpose, 
including a technique based on explicit substitution [4| to track pre- 
cise sources of values. This device is required not only to specify 
DFI precisely but also to prove that our type system enforces DFI. 

We design a simple higher-order process calculus that simu- 
lates Windows Vista's security environment 1311 1171 l43l . In this 
language, processes can fork new processes, create new objects, 
change the labels of processes and objects, and read, write, and ex- 
ecute objects in exactly the same ways as Windows Vista allows. 



Our type system exploits Windows Vista's runtime access checks 
to enforce DFI, and can recognize many correct programs. At the 
same time, our type system subsumes Windows Vista's execution 
controls, allowing them to be optimized away. 

1.1 Summary of contributions 

To sum up, we make the following main contributions in this paper: 

• We propose DFI as a practical multi-level integrity property 
in the setting of Windows Vista, and formalize DFI using a 
semantic technique based on explicit substitution. 

• We present a type system that can efficiently enforce DFI on 
Windows Vista. Typechecking guarantees DFI regardless of 
what untrusted code runs in the environment. 

• We show that while most of Windows Vista's runtime access 
checks are required to enforce DFI, Windows Vista's execution 
controls are redundant and can be optimized away. 

1.2 Outline 

The rest of this paper is organized as follows. In Section [2] we 
introduce Windows Vista's security environment, and show how 
DFI may be violated in that environment. In Section [3] we design 
a calculus that simulates Windows Vista's security environment, 
equip the calculus with a semantics based on explicit substitution, 
and formalize DFI in the calculus. In Section [4] we present a 
system of integrity types and effects for this calculus. In Section|5] 
we prove soundness and other properties of typing. Finally, in 
Section [6] we discuss limitations and contributions with respect 
to related work and conclude. Supplementary material, including 
proof details and an efficient typechecking algorithm, appear in the 
appendix. 

2. Windows Vista's integrity model 

In this section, we provide a brief overview of Windows Vista's 
integrity model(3 In particular, we introduce Windows Vista's se- 
curity environment, and show how DFI may be violated in that en- 
vironment. We observe that such attacks require the participation 
of trusted processes. 

2.1 Windows Vista's security environment 

In Windows Vista, every process and object is tagged with a dy- 
namic integrity label. We indicate such labels in brackets (_) below. 
Labels are related by a total order C, meaning "at most as trusted 
as". Let a range over processes, uj over objects, and P, over la- 
bels. Processes can fork new processes, create new objects, change 
the labels of processes and objects, and read, write, and execute 
objects. In particular, a process with label P can: 

(i) fork a new process a(P); 

(ii) create a new object w(P); 

(iii) lower its own label; 

(iv) change the label of an object u(Q) to O' iff U 0' C P; 

(v) read an object w(0); 

(vi) write an object ui(0) iff OCP; 

(vii) execute an object w(0) by lowering its own label to P l~l 0. 

Rules (i) and (ii) are straightforward. Rule (iii) is guided by the 
principle of least privilege 1341 , and is used in Windows Vista to 
implement a feature called user access control (UAC) 03 1. This 
feature lets users execute commands with lower privileges when 

2 Windows Vista further implements a discretionary access control model, 
which we ignore in this paper. 



appropriate. For example, when a system administrator opens a new 
shell (typically with label High), a new process is forked with label 
Medium; the shell is then run by the new process. When an Internet 
browser is opened, it is always run by a new process whose label 
is lowered to Low; thus any code that gets run by the browser gets 
the label Low — by Rule (i) — and any file that is downloaded by the 
browser gets the label Low — by Rule (ii). 

Rules (iv) and (v) are useful in various ways, but can be dan- 
gerous if not used carefully. (We show some attacks to illustrate 
this point below.) In particular, Rule (iv) allows unprotected ob- 
jects to be protected by trusted processes by raising their labels, 
and Rule (v) allows processes to read objects at lower trust levels. 
At the same time, Rule (iv) facilitates dynamic access control, and 
Rule (v) facilitates communication across trust boundaries. 

Rule (vi) protects objects from being written by processes at 
lower trust levels. Thus, for example, untrusted code forked by a 
browser cannot affect local user files. User code cannot modify 
registry keys protected by a system administrator. Rule (vii) is 
part of UAC; it prevents users from accidentally launching less 
trusted executables with higher privileges. For example, a virus 
downloaded from the Internet cannot run in a trusted user shell. 
Neither can system code dynamically link user libraries. 

2.2 Some attacks 

We now show some attacks that remain possible in this environ- 
ment. Basically, these attacks exploit Rules (iv) and (v) to bypass 
Rules (vi) and (vii). 

(Write and copy) By Rule (vi), a(P) cannot modify uj(0) if P C 
0. However, a(P) can modify some object w'(P), and then 
some process f>(0) can copy a/(P)'s content to w(0). Thus, 
Rule (iv) can be exploited to bypass Rule (vi). 

(Copy and execute) By Rule (vii), a(P) cannot execute uj(0) at 
P if C P. However, a(P) can copy oj(0)'s content to some 
object <j/(P) and then execute u/(P). Thus, Rule (iv) can be 
exploited to bypass Rule (vii). 

(Unprotect, write, and protect) By Rule (vi), a(P) cannot mod- 
ify ^(0) if P C 0. However, some process b(0) can unprotect 
uj(0) to w(P), then a(P) can modify w(P), and then b(0) can 
protect cj(P) back to w(0). Thus, Rule (v) can be exploited to 
bypass Rule (vi). 

(Copy, protect, and execute) By Rule (vii), a(P) cannot execute 
oj(O) at P if C P. However, some process 6(0) can copy 
cj(0)'s content to an object uj'(0), and then a(P) can protect 
cij'(O) to o/(P) and execute o/(P). Thus, Rules (iv) and (v) can 
be exploited to bypass Rule (vii). 

Next, we show that all of these attacks can violate DFI. At the same 
time, we observe that access control forces the participation of a 
trusted process (one with the higher label) in any such attack. 

• In (Write and copy) or (Unprotect, write, and protect), sup- 
pose that the contents of uj(0) are trusted, and P is the label of 
untrusted code, with P C 0. Then data can flow from a(P) to 
a;(0), violating DFI, as above. Fortunately, some process b(0) 
can be blamed here. 

• In (Copy and execute) or (Copy, protect, and execute), sup- 
pose that the contents of some object o/'(P) are trusted, and 
is the label of untrusted code, with OcP. Then data can flow 
from some process b(0) to cu"(P), violating DFI, as follows: 
b(0) packs code to modify o/'(P) and writes the code to w(0), 
and a(P) unpacks and executes that code, as above. Fortunately, 
a(P) can be blamed here. 

Our type system can eliminate such attacks by restricting trusted 
processes (Section [4j. (Obviously, the type system cannot restrict 



untrusted code running in the environment.) Conceptually, this 
guarantee can be cast as Wadler and Findler's "well-typed programs 
can't be blamed" |51| . We rely on the fact that a trusted process 
can be blamed for any violation of DFI; it follows that if all trusted 
processes are well-typed, there cannot be any violation of DFI. 

3. A calculus for analyzing DFI on Windows Vista 

To formalize our approach, we now design a simple higher-order 
process calculus that simulates Windows Vista's security environ- 
ment. We first introduce the syntax and informal semantics, and 
present some examples of programs and attacks in the language. 
We then present a formal semantics, guided by a precise character- 
ization of explicit flows. 

3.1 Syntax and informal semantics 

Several simplifications appear in the syntax of the language. We 
describe processes by their code. We use variables as object names, 
and let objects contain packed code or names of other objects. We 
enforce a mild syntactic restriction on nested packing, which makes 
typechecking significantly more efficient (Appendix |Bj also see 
below). Finally, we elide conditionals — for our purposes, the code 

if condition then a else b 

can be conservatively analyzed by composing a and b in parallel. 
(DFI is a safety property in the sense of JT), and the safety of the 
latter code implies that of the former. We discuss this point in more 
detail in Section EOl ) 

Values include variables, unit, and packed expressions. Expres- 
sions include those for forking new processes, creating new objects, 
changing the labels of processes and objects, and reading, writing, 
and executing objects. They also include standard expressions for 
evaluation and returning results (see Gordon and Hankin's concur- 
rent object calculus 1241 ). 

/, g ::= expression 

ftg fork 

t action 

let x = / in g evaluation 

r result 

t ::= action 

new (a; # S) create object 

[P] a change process label 

(0) uj change object label 

\uj read object 

uj :— x write object 

exec uj execute object 

r ::= result 

x,y,z,...,ui variable 

unit unit 



written as let x = pack(. . . ) in packer).) The benefits of this dis- 
tinction become clear in Section [5] where we discuss mechanical 
typechecking. However, for the bulk of the paper, the reader may 
ignore this distinction; indeed, neither the semantics nor the type 
system are affected by this distinction. 

Processes have the following informal meanings. 

• a I* b forks a new process a with the current process label and 
continues as b (see Rule (i)). 

• new(x # S) creates a new object uj with the current process 
label, initializes uj with x, and returns u (see Rule (ii)); the 
annotation S is used by the type system (Section [4]l and has 
no runtime significance. 

• [P] a changes the current process label to P and continues as 
a; it blocks if the current process label is lower than P (see 
Rule (iii)). 

• (0) uj changes uj's label to and returns unit; it blocks if uj is 
not bound to an object at runtime, or the current process label 
is lower than u)'s label or (see Rule (iv)). 

• \u> returns the value stored in u; it blocks if u> is not bound to 
an object at runtime (see Rule (v)). 

• uj :— x writes the value x to uj and returns unit; it blocks if u> is 
not bound to an object at runtime, or if the current process label 
is lower than ui's label (see Rule (vi)). 

• exec uj unpacks the value stored in w to a process /, lowers the 
current process label with uj's label, and executes /; it blocks if 
uj is not bound to an object at runtime or if the value stored in 
uj is not a packed expression (see Rule (vii)). 

• let x = a in b executes a, binds the value returned by a to x, 
and continues as b with x bound. 

• u returns itself. 

3.2 Programming examples 

We now consider some programming examples in the language. 
We assume that Low, Medium, High, and T are labels, ordered in 
the obvious way. We assume that the top-level process always runs 
with T, which is the most trusted label. 

Example 3.1. Suppose that a Medium user opens an Internet 
browser ie.exe with Low privileges (recall UAC), and clicks on a 
url that contains virus.exe; the virus contains code to overwrite 
the command shell executable cmd.exe, which has label T. 

pi = let cmd.exe = new(. . . # T) in 

let url = [Low] new(. . . # Low) in 

let binlE = pack(let x = !url in exec x) in 

let ie.exe = new(binIE # T) in 



a, b ::= process 

a f b fork 

t action 

let x = a in b evaluation 

U value 

u, v ::= value 

r result 

pack(/) packed expression 

Syntactically, we distinguish between processes and expressions: 
while every expression is a process, not every process is an ex- 
pression. For example, the process pack(/) is not an expression, 
although the process [P] pack(/) is. Expressions can be packed, 
but processes in general cannot. In particular, a process cannot be 
of the form pack(pack(. . . )). (Such a process can, however, be 



[Medium] (. . . C [Low] exec ie.exe) f 

[Low] (let binVirus = pack(cmd.exe :=...) in 

let virus.exe = new(binVirus # Low) in 

url := virus.exe r* 

...) 

This code may eventually reduce to 

qi = [Medium] (. . . I* [Low] cmd.exe :=...) f 
[Low](...) 

However, at this point the write to cmd.exe blocks due to access 
control. (Recall that a process with label Low cannot write to an 
object with label T.) 



Example 3.2. Next, consider the following attack, based on the 
(Copy, protect, and execute) attack in Section [Z2l A Medium user 
downloads a virus from the Internet that contains code to erase the 
user's home directory (home), and saves it by default in setup.exe. 
A High administrator protects and executes setup.exe. 

P2 = leturl = [Low] new(. . . # Low) in 

let setup.exe = [Low] new(. . . # Low) in 
let binlE = pack(let z = !url in 

let x = \z\n setup.exe := x) in 
let ie.exe = new(binIE # T) in 
let home = [Medium] new(. . . # Medium) in 
let empty = unit in 

[High] (•■•[> 

let _ = (High) setup.exe in 
exec setup.exe) r* 
[Medium] (. . . P* [Low] exec ie.exe) f 
[Low] (letbinVirus = pack(home := empty) in 
let virus.exe = new(binVirus # Low) in 
url := virus.exe C 



This code may eventually reduce to 

<12 — [High] (. . . r* home := empty) f 



[Medium] (. 
[Low](...) 



■) I* 



The user's home directory may be erased at this point. (Recall that 
access control does not prevent a process with label High from 
writing to an object with label Medium.) 

3.3 An overview of DFI 

Informally, DFI requires that objects whose contents are trusted at 
some label S never contain values that flow from labels lower than 
S. In Example 13.11 we trust the contents of cmd.exe at label T, 
as declared by the static annotation T. DFI is not violated in this 
example, since access control prevents the flow of data from Low to 
cmd.exe. On the other hand, in Example l3.2l we trust the contents 
of home at label Medium. DFI is violated in this example, since the 
value empty flows from Low to home. 

By design, DFI is a safety property (7) — roughly, it can be 
defined as a set of behaviors such that for any behavior that not in 
that set, there is some finite prefix of that behavior that is not in that 
set. To that end, DFI considers only explicit flows of data. Denning 
and Denning characterizes explicit flows 1181 roughly as follows: 
a flow of x is explicit if and only if the flow depends abstractly on 
x (that is, it depends on the existence of x, but not on the value 
x). Thus, for example, the violation of DFI in Example 13.21 does 
not depend on the value empty — any other value causes the same 
violation. Conversely, empty is not dangerous in itself. Consider 
the reduced process q-2 in Example l3.2l Without any knowledge of 
execution history, we cannot conclude that DFI is violated in q^. 
Indeed, it is perfectly legitimate for a High-process to execute the 
code 

home := empty 

intentionally, say as part of administration. However, in Exam- 
ple 13.21 we know that this code is executed by unpacking some 
code designed by a Low-process. The violation of DFI is due to 
this history. 



It follows that in order to detect violations of DFI, we must dis- 
tinguish between various instances of a value, and track the sources 
of those instances during execution. We maintain this execution 
history in the operational semantics (Section [3.4t . by a technique 
based on explicit substitution PI , 

Before we move on, let us ease the tension between DFI and 
conditionals. In general, conditionals can cause implicit flows 1181 : 
a flow of x can depend on the value x if x appears in the condition 
of some code that causes that flow. For example, the code 

if x = zero then to := zero else uj := one 

causes an implicit flow of a; to a; that depends on the value x. 
We can abstract away this dependency by interpreting the code 
if condition then a else b as the code a t b. Recall that DFI is a 
safety property. Following 1331 , the safety of a [* b can be expressed 
by the logical formula F = F a A Ff,, where F a is the formula that 
expresses the safety of a, and Fb is the formula that expresses the 
safety of b. Likewise, the safety of if condition then a else b 
can be expressed by the formula F' = (condition =>■ F a ) A 
(-■condition => Ft). Clearly, we have F =>- F', so that the code 
if condition then a else b is a refinement of the code a f b.It is 
well-known that safety is preserved under refinement 1331 . 

But implicit flows are of serious concern in many applications; 
one may wonder whether focusing on explicit flows is even desir- 
able. Consider the code above; the implicit flow from x to u vio- 
lates noninterference, if x is an untrusted value and the contents of 
uj are trusted. In contrast, DFI is not violated in the interpreted code 

uj := zero f uj :— one 

if zero and one are trusted values. Clearly, DFI ignores the implicit 
flow from x to uj. But this may be fine — DFI can be used to prove 
an invariant such as "the contents of uj are always boolean values". 
Note that the code 



does not maintain this invariant, since x may be an arbitrary value. 
Thankfully, DFI is violated in this code. 

3.4 An operational semantics that tracks explicit flows 

We now present a chemical-style operational semantics for the 
language, that tracks explicit flows[j We begin by extending the 
syntax with some auxiliary forms. 



a, b 





UJ X 



{vx/p@P) a 
u 

new(x # S) 



process 

source process 

store 

explicit substitution 
substituted value 
value 

object initialization 



The process uj i— > x asserts that the object uj contains x and is 
protected with label 0. A key feature of the semantics is that objects 
store values "by instance" — only variables may appear in stores. 
We use explicit substitution to track and distinguish between the 
sources of various instances of a substituted value. Specifically, the 
process (yx/pMP) a creates a fresh variable x, records that x is 
bound to zi by a process with label P, and continues as a with x 
bound. Here a; is an instance of p and P is the source of x. If \i 
is a value, then this process is behaviorally equivalent to a with x 
substituted by p. For example, in Example 13.21 the source of the 
instance of empty in binVirus is Low; this fact is described by 



3 This presentation is particularly convenient for defining and proving DFI; 
of course, a concrete implementation of the language may rely on a lighter 
semantics that does not track explicit flows. 



Local reduction a —-^ b 



(Reduct evaluate) 



let x — u in a (yx/u@P) a 



(Reduct new) 



new(x # S) — > (vuj/new(x # S)@P) (uj £ x I* uj) 



(Reduct read) 



(Reduct write) 



O & . / P;ct O & 
I — ^ X V \UJ > UJ I — > XIX 



0^1 P;ct O rt 

w _ r lj := x — > uj i — y x r unit 



(Reduct execute) 

a> = w' pack(/) G <7(a:) P' = P n 

O . / P;ct O . , n /, , 

uj ^ x v exec uj — > uj h- > x r [P J / 

(Reduct un/protect) 

w = J OuO'cP 



r> /r>'\ ' P;<T °' r* 

w a; r (O ) uj — > w h> i r unit 



Structural equivalence a = b 



(Struct bind) 

£ P]a {a{x/y}\ P ,^ = £ P .,4(vx/y@P') aj P ,. a , 

(Struct substitution) 

x £ fv(£p, a ) U bv(£ P , CT ) fvf» n bv(£ P , CT ) = 

£p:vl(vx/n@P") a]p/, CT / EE {l/x/fMP") £p, W)1 8P»)Ua[<llf 

(Struct fork) 



fv(a) nbv(£ P;( 



(Struct store) 



[P] (u A x f a) = w A x [» [P] a 



(Struct equiv) 



= is an equivalence 



rewriting the process 52 as 

(i/z/emptyOLow) [High] (•••[* home := x) f* . . . 

DFI prevents this particular instance (x) of empty from being 
written to home; but it allows other instances whose sources are 
at least as trusted as Medium. The rewriting follows a structural 
equivalence rule (Struct bind), explained later in the section. 

While explicit substitution has been previously used in language 
implementations, we seem to be the first to adapt this device to 
track data flow in a concurrent language. In particular, we use 
explicit substitution both to specify DFI (in Definitions l3.3l and l3.4t 
and to verify it statically (in proofs of Theorems 15.41 and 15. 1\ . We 
defer a more detailed discussion on this technique to Section|6] 

We call sets of the form {xi/^i@Pi, . . . , Xk/ Hk@Pk} substi- 
tution environments. 

Definition 3.3 (Explicit flows). A variable x flows from a label 

a 

P or lower in a substitution environment o, written x ▼ P, if 
x//i@P' £ a for some \i and P' such that either P' C P, or /i 

is a variable and (inductively) (iTP. 

In other words, x flows from a label P or lower if x is an 
instance of a value substituted at P or lower. In Definition 13.41 
below, we formalize DFI as a property of objects, as follows: an 
object is protected from label L if it never contains instances that 
flow from L or lower. We define o-(x) to be the set of values 
in a that x is an instance of: x £ o~(x), and if (inductively) 
y £ o~(x) and y/u@ _ 6 a for some y and u, then u £ a(x). 
The operational semantics ensures that substitution environments 
accurately associate instances of values with their runtime sources. 

We now present rules for local reduction, structural equivalence, 

and global reduction. Reductions are of the form a — ^> b, mean- 
ing that "process a may reduce to process b with label P in sub- 
stitution environment a". Structural equivalences are of the form 
a = b, meaning that "process a may be rewritten as process b". 
The notions of free and bound variables (f v and bv) are standard. 
We write x = y if cr(x) PI c(y) 7^ 0, that is, there is a value that 
both x and y are instances of. 

We first look at the local reduction rules. In (Reduct evaluate), 
a substitution binds x to the intermediate value u and associates 
x with its runtime source P. (Reduct new) creates a new store 
denoted by a fresh variable uj, initializes the store, and returns 
uj; a substitution binds uj to the initialization of the new object 
and associates uj with its runtime source P. The value x and the 
trust annotation S in the initialization are used by the type system 
(Section[4]L The remaining local reduction rules describe reactions 
with a store, following the informal semantics. 

Next, we define evaluation contexts 1201 . An evaluation context 
is of the form £p la , and contains a hole of the form •p/ ;cr i', the 
context yields a process that executes with label P in substitution 
environment a, if the hole is plugged by a process that executes 
with label P' in substitution environment a'. 



Global reduction a 



(Reduct context) 



a > 



(Reduct congruence) 



a = a a > 0=0 

a > 



£ P ;o '■■= 

•P;a 

let x = £p-cr in b 

£p;a I* b 
a I* £p ; (j 

[P'} S P ,. a (P' C P) 



evaluation context 
hole 

sequential evaluation 
fork left 
fork right 

explicit substitution 
lowering of process label 



Evaluation can proceed sequentially inside let processes, and in 
parallel under forks 1241 ; it can also proceed under explicit sub- 
stitutions and lowering of process labels. In particular, note how 
evaluation contexts build substitution environments from explicit 
substitutions, and labels from changes of process labels. We denote 



by £p ;<T [a]p/ ;(T / the process obtained by plugging the hole •pr. a .i in 
£p ;a with a. 

Next, we look at the structural equivalence and global reduction 
rules. In (Struct bind), a{x/y} is the process obtained from a 
by the usual capture-avoiding substitution of x by y. The rule 
states that explicit substitution may invert usual substitution to 
create instances as required. In particular, variables that appear in 
packed code can be associated with the label of the process that 
packs that code, even though those variables may be bound later — 
by (Reduct evaluate) — when that code is eventually unpacked at 
some other label. For example, the instance of empty in binVirus 
may be correctly associated with Low (the label at which it is 
packed) instead of High (the label at which it is unpacked). Thus, in 
combination, the rules (Reduct evaluate) and (Struct bind) track 
precise sources of values by explicit substitution. 

By (Struct substitution), substitutions can float across contexts 
under standard scoping restrictions. By (Struct fork), forked pro- 
cesses can float across contexts 1241 . but must remain under the 
same process label. By (Struct store), stores can be shared across 
further contexts. 

Reduction is extended with contexts and structural equivalence 
in the natural way. 

Finally, we formalize DFI in our language, as promised. 

Definition 3.4 (DFI). The object lo is protected from label L by 
process a if there is no process b, substitution environment a, and 

instance x such that a r* [L] b £t,iz [w ^ x}t,o- and iTL. 

4. A type system to enforce DFI 

We now show a type system to enforce DFI in the language. (The 
formal protection guarantee for well-typed code appears in Sec- 
tion[5]) We begin by introducing types and typing judgments. We 
then present typing rules and informally explain their properties. 
Finally, we consider some examples of typechecking. An efficient 
algorithm for typechecking is outlined in Appendix |B1 

4.1 Types and effects 

The core grammar of types is shown below. Here effects are simply 
labels; these labels belong to the same ordering C as in the opera- 
tional semantics. 



Core typing judgments r h P a : T 



Obj(T) 
V P . Bin(T) 
Unit 



T 



type 

object 

packed code 
unit 

static approximation 
type and effect 



• The type Obj(r s ) is given to an object that contains values of 
type t. Such contents may not flow from labels lower than S; in 
other words, S indicates the trust on the contents of this object. 
DFI follows from the soundness of object types. 

• The type Vp. Bin(r E ) is given to packed code that can be run 
with label P. Values returned by the code must be of type r and 
may not flow from labels lower than E. In fact, our type system 
admits a subtyping rule that allows such code to be run in a 
typesafe manner with any label that is at most P. 

• The effect E is given to a value that does not flow from labels 
lower than E. 

When creating an object, the programmer declares the trust on the 
contents of that object. Roughly, an object returned by new(_# S) 
gets atype Obj(_ s ). For example, in Examples l3.ll andl 3.2l we de- 
clare the trust T on the contents of cmd.exe and the trust Medium 
on the contents of home. 



(Typ unit) 
(Typ variable) 

(Typ fork) 

(Typ limit) 

(Typ evaluate) 



T hp unit : Unit; 

x : r E 6 T 

T-i I EnP 
1 hp x : r 

T hp a : . T hp b : T 
r hp a f b : T 

T hp/ a : T 
T hp [P 7 ] a : T 

rh P a:T' T,x :T' h P b:T 
T hp let x = a in b : T 

(Typ substitute) 

T hp/ ii :T' F,x:T' h P a : T 



T hp {vx/liW) a : T 



(Typ store) 



{fj:Obj(r S )-,i:r E }Cr SCOnE 



(Typ new) 



(Typ pack) 



1 I p LO I — ► X '. _ 

r hp x : t E SCE 
Thp new(a:#S) : Obj(r S ) P 

£ Hp; f:T □/ 
T hp pack(/) : V P /. Bin(T) F 



(Typ un/protect) 



T hp lo : Obj(_ ) b SCO 
T hp (0) lo : Unit P 



*P => *E 



(Typ write) 

Thptu : Obj(r S ) E F h P x : r E ' S C E' 



(Typ read) 



r hp u> := x : Unit 



lo : Obj(r S ) E S r 



*P => *E 



r hp \lo : r 



SnP 



(P nS) *E 



(Typ execute) 

lo : Obj((Vp/. Bin(r E ')) S ) E G T P C P' n S 



r hp exec lo : r 



E'nP 



nP => *E 



A typing environment F contains typing hypotheses of the form 
x : T. We assume that any variable has at most one typing hypothe- 
sis in r, and define dom(r) as the set of variables that have typing 
hypotheses in F. A typing judgment is of the form F hp a : T, 
where P is the label of the process a, T is the type and effect of 
values returned by a, and f v(a) C dom(T). 

4.2 Core typing rules 

In the previous page, we present typing rules that enforce the 
core static discipline required for our protection guarantee. Some 
of these rules have side conditions that involve a predicate * on 

labels. These conditions, which are marked in shaded boxes , are 
ignored in our first reading of these rules. (The predicate * is true 
everywhere in the absence of a special label _L, introduced later 
in the section.) One of the rules has a condition that involves a 
predicate □ on expressions; we introduce that predicate in the 
discussion below. The typing rules preserve several invariants. 

(1) Code that runs with a label P cannot return values that have 
effects higher than P. 

(2) The contents of an object of type Obj(_ s ) cannot have effects 
lower than S. 

(3) The dynamic label that protects an object of type Obj(_ s ) 
cannot be lower than S. 

(4) An object of type Obj(_ s ) cannot be created at a label lower 
than S. 

(5) Packed code of type Vp. Bin(_) must remain well-typed 
when unpacked at any label lower than P. 

Invariant (1) follows from our interpretation of effects. To preserve 
this invariant in (Typ variable), for example, the effect of x at P is 
obtained by lowering x's effect in the typing environment with P. 

In (Typ store), typechecking is independent of the process 
label, that is, a store is well-typed if and only if it is so at any 
process label; recall that by (Struct store) stores can float across 
contexts, and typing must be preserved by structural equivalence. 
Further, (Typ store) introduces Invariants (2) and (3). Invariant 

(2) follows from our interpretation of static trust annotations. To 
preserve this invariant we require Invariant (3), which ensures that 
access control prevents code running with labels less trusted than S 
from writing to objects whose contents are trusted at S. 

By (Typ new), the effect E of the initial content of a new 
object cannot be lower than S. Recall that by (Reduct new), the 
new object is protected with the process label P; since P □ E 
by Invariant (1), we have P □ S, so that both Invariants (2) and 

(3) are preserved. Conversely, if P C S then the process does not 
typecheck; Invariant (4) follows. 

Let us now look carefully at the other rules relevant to Invari- 
ants (2) and (3); these rules — combined with access control — are 
the crux of enforcing DFI. (Typ write) preserves Invariant (2), re- 
stricting trusted code from writing values to ui that may flow from 
labels lower than S. (Such code may not be restricted by access 
control.) Conversely, access control prevents code with labels lower 
than S from writing to u), since by Invariant (3), uj's label is at least 
as trusted as S. (Typ un/protect) preserves Invariant (3), allowing 
w's label to be either raised or lowered without falling below S. 
In (Typ read), the effect of a value read from uj at P is approxi- 
mated by S — the least trusted label from which w's contents may 
flow — and further lowered with P to preserve Invariant (1). 

In (Typ pack), packing code requires work akin to proof- 
carrying code 1391 . Type safety for the code is proved and "carried" 
in its type Vp/. Bin(T), independently of the current process la- 
bel. Specifically, it is proved that when the packed code is unpacked 
by a process with label P', the value of executing that code has type 



and effect T. In Section[5]we show that such a proof in fact allows 
the packed code to be unpacked by any process with label P C P', 
and the type and effect of the value of executing that code can 
be related to T (Invariant (5)). This invariant is key to decidable 
and efficient typechecking (Appendix [Bj. Of course, code may 
be packed to run only at specific process labels, by requiring the 
appropriate label changes. 

Preserving Invariant (5) entails, in particular, preserving Invari- 
ant (4) at all labels P C. P'. Since a new expression that is not 
guarded by a change of the process label may be run with any label 
P, that expression must place the least possible trust on the contents 
of the object it creates. This condition is enforced by predicate □: 



□ new(x#S) 

□(/ 1* g) 

□ (let x = f in g) 
□ (...) 



VP. SCP 

□/ A Ug 
□ / A Ug 
true 



(Typ execute) relies on Invariant (5); further, it checks that the 
label at which the code is unpacked (P) is at most as trusted as 
the label at which the code may have been packed (approximated 
by S). This check prevents privilege escalation — code that would 
perhaps block if run with a lower label cannot be packed to run 
with a higher label. For example, recall that in Example 13.21 the 
code binVirus is packed at Low and then copied into setup.exe. 
While a High-process can legitimately execute home := empty 
(so that the code is typed and is not blocked by access control), it 
should not run that code by unpacking binVirus from setup.exe. 
The type system prevents this violation. Let setup.exe be of type 
Obj((V_. Bin(.)) s ). Then (Typ store) requires that S C Low, 
and (Typ execute) requires that High C S (contradiction). 

Because we do not maintain an upper bound on the dynamic 
label of an executable, we cannot rely on the lowering of the 
process label in (Reduct execute) to prevent privilege escalation. 
(While it is possible to extend our type system to maintain such 
upper bounds, such an extension does not let us typecheck any more 
correct programs than we already do.) In Section [5] we show that 
the lowering of the process label can in fact be safely eliminated. 

In (Typ evaluate), typing proceeds sequentially, propagating 
the type and effect of the intermediate process to the continuation. 
(Typ substitution) is similar, except that the substituted value is 
typed under the process label recorded in the substitution, rather 
than under the current process label. In (Typ limit), the continua- 
tion is typed under the changed process label. In (Typ fork), the 
forked process is typed under the current process label. 

4.3 Typing rules for stuck code 

While the rules above rely on access control for soundness, they do 
not exploit runtime protection provided by access control to type- 
check more programs. For example, the reduced process gi in Ex- 
ample [3~Tl cannot yet be typed, although we have checked that DFI 
is not violated in q\ . Below we introduce stuck typing to identify 
processes that provably block by access control at runtime. Stuck 
typing allows us to soundly type more programs by composition. 
(The general principle that is followed here is that narrowing the 
set of possible execution paths improves the precision of the anal- 
ysis.) This powerful technique of combining static typing and dy- 
namic access control for runtime protection is quite close to hybrid 
typechecking [21 :|. We defer a more detailed discussion of this tech- 
nique to Section|6] 

We introduce the static approximation Stuck for processes that 
do not return values, but may have side effects. 
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code 



Stuck typing judgments r h P a : Stuck 



Typing rules for untrusted code 



(Typ escalate stuck) 



PcP' 



r hp [P'] a : Stuck 



(Typ write stuck) 



w : Obj(. b ) E e r Pes 

r hp ui :— x : Stuck 

(Typ un/protect stuck) 

w:Obj(_ S ) E Gr PcSuO 
r hp (O) to : Stuck 

(Typ subsumption stuck-I) 

_ : Stuck G T 



r hp a : Stuck 



(Typ subsumption stuck-II) 

r hp a : Stuck 

T hp a : T 



Stuck 



stuck process 



We now present rules for stuck-typing. As before, in our first read- 
ing of these rules we ignore the side conditions in shaded boxes 
(which involve the predicate *). (Typ write stuck) identifies code 
that tries to write to an object whose static trust annotation S is 
higher than the current process label P. By Invariant (3), the la- 
bel that protects the object must be at least as high as S; thus 
P □ and the code must block at runtime due to access control. 
For example, let cmd.exe be of type Obj(_ T ) in Example l3.ll By 
(Typ write stuck), the code qi is well-typed since Low C T. (Typ 
un/protect stuck) is similar to (Typ write stuck); it further identi- 
fies code that tries to raise the label of an object beyond the current 
process label. (Typ escalate stuck) identifies code that tries to raise 
the current process label. All such processes block at runtime due 
to access control. 

By (Typ subsumption stuck-I), processes that are typed under 
stuck hypotheses are considered stuck as well. For example, this 
rule combines with (Typ evaluate) to trivially type a continuation 
b if the intermediate process a is identified as stuck. Finally, by 
(Typ subsumption stuck-II), stuck processes can have any type 
and effect, since they cannot return values. 

4.4 Typing rules for untrusted code 

Typing must guarantee protection in arbitrary environments. Since 
the protection guarantee is derived via a type preservation theorem, 
arbitrary untrusted code needs to be accommodated by the type 
system. We assume that untrusted code runs with a special label 
_L, introduced into the total order by assuming 1 C L for all L. We 
now present rules that allow arbitrary interpretation of types at _L. 
By (Typ subsumption _L-I), placing the static trust _L on the 
contents of an object amounts to assuming any type for those 
contents as required. By (Typ subsumption -L-IT), a value that 
has effect _L may be assumed to have any type as required. These 
rules provide the necessary flexibility for typing any untrusted code 
using the other typing rules. On the other hand, arbitrary subtyping 
with objects can in general be unsound — we now need to be careful 



(Typ subsumption _L-I) 



r,ui : Obj(_ ) E hp a : T 
F,uj : Obj(r x ) E hp a : T 



(Typ subsumption _L-II) 

r,x 



hp a : T 



T,x : t hp a : T 



when typing trusted code. For example, consider the code 



High 

UJ2 1 — y X 



^ Low 

V I — ► L02 



I* [High] let z = !wi in z 



A High-process reads the name of an object (u>2) from a Low-object 
(wi), and then writes u to that object (wa). DFI is violated if u>2 
has type Obj(_ Hlgh ) and u flows from Low. Unfortunately, it turns 
out that this code can be typed under process label T and typing 
hypotheses 



lj 2 : Obj(r : 



Highx 



wi : Obj(Obj(T 2 High n 



u : T\ 



Specifically, the intermediate judgment 



Obj(r 2 High ) 



Low i 

,u:t 1 hHigh z :=u 



can be derived by adjusting the type of z in the typing environment 
to Obj(r! Low ) with (Typ subsumption _L-II). 

This source of unsoundness is eliminated if some of the effects 
in our typing rules are required to be trusted, that is, to be higher 
than _L. Accordingly we introduce the predicate *, such that for 
any label L, *L simply means L □ _L. We now revisit the typ- 
ing rules earlier in the section and focus on the side conditions in 

shaded boxes (which involve *). In some of those conditions, we 
care about trusted effects only if the process label is itself trusted. 
With these conditions, (Typ write) prevents typechecking the of- 
fending write above, since the effect of z in the typing environment 
is untrusted. 

4.5 Compromise 

The label _L introduced above is an artificial construct to tolerate 
a degree of "anarchy" in the type system. We may want to specify 
that a certain label (such as Low) acts like _L, i.e., is compromised. 
The typing judgment V hp a : T despite C allows us to type 
arbitrary code a running at a compromised label C by assuming that 
C is the same as _L, i.e., by extending the total order with C C _L 
(so that all labels that are at most as trusted as C collapse to _L). 
We do not consider labels compromised at runtime (as in Gordon 
and Jeffrey's type system for conditional secrecy 1261 ); however 
we do not anticipate any technical difficulty in including runtime 
compromise in our type system. 

4.6 Typechecking examples 

We now show some examples of typechecking. 

We begin with the program p2 in Example l3.2l Recall that DFI 
is violated inp2. Suppose that we try to derive the typing judgment 

■ ■ ■ I — r P2 ■ - despite Low 

This amounts to deriving • • • I — r P2 : - by assuming Low C J_. 

As a first step, we apply (Typ new), (Typ read), (Typ write), 
(Typ pack), and (Typ evaluate), directed by syntax, until we have 



the following typing environment. 

r = 

url : Obj(. Lo ™) T , 

setup.exe : Obj(_ Low ) T , 

binlE : (V Lo w- Bin(Unit)) T , 

ie.exe : Obj((VLow- Bin(Unit)) T ) T , 

, • / Medium \T 

home : (Jbj(_ ) 
empty : Unit T 

The only complication that may arise is in this step is in deriving 
an intermediate judgment 

Low i i 

z : . h T iz : - 

Here, we can apply (Typ subsumption _L-II) to adjust the typing 
hypothesis of z to Obj(_) x , so that (Typ read) may apply. 
After this step, we need to derive a judgment of the form: 

Thy [High](...) t [Medium] (...) [* [Low] (. . . ) 

Now, we apply (Typ fork). We first check that the code [Low] (...) 
is well-typed. (In fact, untrusted code is always well-typed, as we 
show in Section[5]) The judgment 

r h|_ w home := empty : Unit 

typechecks by (Typ write stuck). Thus, by (Typ pack) and (Typ 
evaluate), we add the following hypothesis to the typing environ- 
ment. 

binVirus : (V Lo w Bin(Unit)) Low 
Let Tbinvirus = (Vlow Bin(Unit ) ) Low . Next, by (Typ new) and 
(Typ evaluate), we add the following hypothesis to the typing 
environment. 

virus.exe : Obj(T b invirus) Low 
Finally, the judgment 

T, . . . , virus.exe : Obj(T bin vi rus ) L ° w h Low url := virus.exe 

can be derived by (Typ write), after massaging the typing hypothe- 
sis for virus.exe to the required _ Low by (Typ subsumption _L-H). 

On the other hand, the process [High] (...) does not typecheck; 
as seen above, an intermediate judgment 

T I - High exec setup.exe : _ 

cannot be derived, since (Typ execute) does not apply. 

To understand this situation further, let us consider some varia- 
tions where (Typ execute) does apply. Suppose that the code exec z 
is forked in a new process whose label is lowered to Low. Then p2 
typechecks. In particular, the following judgment can be derived by 
applying (Typ execute). 

T hHigh [Low] exec setup.exe : _ 

Fortunately, the erasure of home now blocks by access control at 
runtime, so DFI is not violated. 

Next, suppose that the static annotation for setup.exe is High 
instead of Low, and setup.exe is initialized by a process with 
label High instead of Low. Then P2 typechecks. In particular, the 
type of setup.exe in T becomes Obj(_ Hlgh ). We need to derive an 
intermediate judgment 

r, . . . , x : _ hi_ow setup.exe := x : Unit 

This judgment can be derived by applying (Typ write stuck) in- 
stead of (Typ write). Fortunately, the overwrite of setup.exe now 
blocks by access control at runtime, so DFI is not violated. 

Finally, we sketch how typechecking fails for the violations of 
DFI described in Section [2~2| 



(Write and copy) Let the type of u be Obj(_ s ), where □ S □ 
P. Then the write to w(0) does not typecheck, since the value 
to be written is read from w'(P) and thus has some effect E such 
that E C P, so that EcS. 

(Copy and execute) Let the type of J be Obj(_ s ). If S' C 
then the execution of o/(P) by q(P) does not typecheck, since 
S' C P. If S' □ then the write to u/(P) does not typecheck, 
since the value to be written is read from w(O) and thus has 
some effect E such that E C 0, so that E C S'. 

(Unprotect, write, and protect) Let the type of w be Obj(_ s ), 
where □ S □ P. Then the unprotection of w(0) does not 
typecheck, since P □ S. 

(Copy, protect, and execute) Let the type of u/ be Obj(_ s ), 
where S' C. 0. Then the execution of w'(P) does not type- 
check, since S' C P. 

5. Properties of typing 

In this section we show several properties of typing, and prove 
that DFI is preserved by well-typed code under arbitrary untrusted 
environments. All proof details appear in AppendixlAl 

We begin with the proposition that untrusted code can always 
be accommodated by the type system. 

Definition 5.1 (Adversary). A C-adversary is any process of the 
form [C] _ that does not contain stores, explicit substitutions, and 
static trust annotations that are higher than C. 

Proposition 5.2 (Adversary completeness). Let Y be any typing 
environment and c be any C-adversary such that f v(c) C dom(r). 
Then T I — r c : _ despite C. 

Proposition 15.21 provides a simple way to quantify over arbi- 
trary environments. By (Typ fork) the composition of a well-typed 
process with any such environment remains well-typed, and thus 
enjoys all the properties of typing. 

Next, we present a monotonicity property of typing that is key 
to decidable and efficient typechecking (Appendix |BV 

Proposition 5.3 (Monotonicity). The following inference rule is 
admissible. 

T hp, / : r E □/ PCP' 

i_ 7 EnP 
T hp / : t 

This rule formalizes Invariant (5), and allows inference of "most 
general" types for packed code (Appendix [B}. Further, it implies 
an intuitive proof principle — code that is proved safe to run with 
higher privileges remains safe to run with lower privileges, and con- 
versely, code that is proved safe against a more powerful adversary 
remains safe against a less powerful adversary. 

The key property of typing is that it is preserved by structural 
equivalence and reduction. Preservation depends delicately on the 
design of the typing rules, relying on the systematic maintenance of 
typing invariants. We write r h a, meaning that "the substitution 
environment o is consistent with the typing environment V", if for 
all x/u@ Pea there exists T such that x : T € L and T h P u : T. 

Theorem 5.4 (Preservation). Suppose that V h o and Y hp a : _. 

Then 

• if a = b then V hp b : _; 

• if a — > b then T hp b : _ 

We now present our formal protection guarantee for well-typed 
code. We begin by strengthening the definition of DFI in Section[3] 
In particular, we assume that part of the adversary is known and part 
of it is unknown. This assumption allows the analysis to exploit any 



sound typing information that may be obtained from the known part 
of the adversary. (As a special case, the adversary may be entirely 
unknown, of course. In this case, we recover Definition 13.41 see 
below.) Let SI be the set of objects that require protection from 
labels L or lower. We let the unknown part of the adversary execute 
with some process label C (C L). We say that Q is protected if no 
such adversary can write any instance that flows from L or lower, 
to any object in Q. 

Definition 5.5 (Strong DFI). A set of objects SI is protected by 
code a from label L despite C ("C L) if there is no U) 6 O, C- 
adversary c, substitution environment a, and instance x such that 

a? c —5* £ T ,g\uj ^ x]t,ct and x ▼ L. 

For example, we may want to prove that some code protects a 
set of High-objects from Medium despite (the compromised label) 
Low; then we need to show that no instance may flow from Medium 
or lower to any of those High -objects under any Low-adversary. 

We pick objects that require protection based on their types and 
effects in the typing environment. 

Definition 5.6 (Trusted objects). The set of objects whose contents 
are trusted beyond the label L in the typing environment T is 
{lu\lu: Obj(l s ) E G T and S n E □ L}. 

Suppose that in some typing environment, S7 is the set of ob- 
jects whose contents are trusted beyond label L, and C (C L) is 
compromised; we guarantee that S7 is protected by any well-typed 
code from L despite C. 

Theorem 5.7 (Enforcement of strong DFI). Let S7 be the set of 

objects whose contents are trusted beyond L in T. Suppose that 
T I — r a : _ despite C, where C C L. Then a protects S7 from L 
despite C. 

In the special case where the adversary is entirely unknown, we 
simply consider L and C to be the same label. 

The type system further enforces DFI for new objects, as can be 
verified by applying Theorem 15. 41 (Typ substitute), and Theorem 
15.71 Finally, the type system suggests a sound runtime optimization: 
whenever a well-typed process executes packed code in a trusted 
context, the current process label is already appropriately lowered 
for execution. 

Theorem 5.8 (Redundancy of execution control). Suppose that 
r I — r a : _ despite C and a ii?>* £ t . \lo A _ \> exec u/J P;o . 
such that lo = lo' and P □ C. Then PCO. 

It follows that the rule (Reduct execute) can be safely opti- 
mized as follows. 

lo = lo' pack(/) G cr(x) 

r> I P ' a r» J- 

lo i — > x r exec lo — > lo x V j 

This optimization should not be surprising. Lowering the process 
label for execution aims to prevent trusted code from executing 
untrusted code in trusted contexts; our core static discipline on 
trusted code effectively subsumes this runtime control. On the other 
hand, write-access control cannot be eliminated by any discipline 
on trusted code, since that control is required to restrict untrusted 
code. 

Lastly, typechecking can be efficiently mechanized thanks to 
Proposition 1 5 . 3 1 and our syntactic restriction on nested packing. A 
typechecking algorithm is outlined in Appendix [Bl 

Theorem 5.9 (Typechecking). Given a typing environment Y and 
code a with L distinct labels, the problem of whether there exists T 
such that r I — r a : T, is decidable in time C(L|a|), where \a\ is 
the size of a. 



6. Limitations, related work, and discussion 

In this paper we formalize DFI — a multi-level integrity property 
based on explicit flows — and present a type system that can effi- 
ciently enforce DFI in a language that simulates Windows Vista's 
security environment. 

Not surprisingly, our type system is only a conservative tech- 
nique to enforce DFI — while every program that typechecks is 
guaranteed to satisfy DFI (as stated in Theorem l5.7t . well-typedness 
is not necessary for DFI. 

By design, our analysis is control-insensitive — it does not track 
implicit flows. In many applications, implicit flows are of serious 
concern. It remains possible to extend our analysis to account for 
such flows, following the ideas of 1501 1541 [3811361 . However, we 
believe that it is more practical to enforce a weaker property like 
DFI at the level of an operating system, and enforce stronger, 
control-sensitive properties like noninterference at the level of the 
application, with specific assumptions. 

Our core security calculus is simplified, although we take care 
to include all aspects that require conceptual modeling for reason- 
ing about DFI. In particular, we model threads, mutable references, 
binaries, and data and code pointers; other features of x86 binaries, 
such as recursion, control flow, and parameterized procedures, can 
be encoded in the core calculus. We also model all details of Win- 
dows Vista that are relevant for mandatory integrity control with 
dynamic labels. On the other hand, we do not model details such as 
discretionary access control, file virtualization, and secure autho- 
rization of privilege escalation 1311 . which can improve the preci- 
sion of our analysis. Building a typechecker that works at the level 
of x86 binaries and handles all details of Windows Vista requires 
more work. At the same time, we believe that our analysis can be 
applied to more concrete programming models by translation. 

Our work is closely related to that of Tse and Zdancewic 1481 
and Zheng and Myers [59] on noninterference in lambda calculi 
with dynamic security levels. While Tse and Zdancewic do not 
consider mutable references in their language, it is possible to 
encode the sequential fragment of our calculus in the language of 
Zheng and Myers; however, well-typed programs in that fragment 
that rely on access control for DFI do not remain well-typed via 
such an encoding. Specifically, any restrictive access check for 
integrity in the presence of dynamically changing labels seems to 
let the adversary influence trusted computations in their system, 
violating noninterference 1581 . 

Noninterference is known to be problematic for concurrent lan- 
guages. In this context, Zdancewic and Myers study the notion of 
observational determinism 1561 ; Abadi, Hennessy and Riely, and 
others study information flow using testing equivalence IT1 I28I ; and 
Boudol and Castellani, Honda and Yoshida, and others use stronger 
notions based on observational equivalence ||10||29| . Sophisticated 
techniques that involve linearity, race analysis, behavior types, and 
liveness analysis also appear in the literature [ 29 , 56 28 , 32 1 . While 
most of these techniques are developed in the setting of the pi cal- 
culus, other works consider distributed and higher-order settings to 
study mobile code I27ll53ll45l (as in this work). 

DFI being a safety property (7) gets around some of the dif- 
ficulties posed by noninterference. A related approach guides the 
design of the operating systems Asbestos 1191 and HiStar 1571 . and 
dates back to the Clark- Wilson approach to security in commercial 
computer systems 1151 1461 . In comparison with generic models of 
trace-based integrity that appear in protocol analysis, such as cor- 
respondence assertions [25. 22 j, our integrity model is far more 
specialized; as a consequence, our type system requires far less an- 
notations than type systems for proving correspondence assertions. 

Our definition of DFI relies on an operational semantics based 
on explicit substitution. Explicit substitution, as introduced by 
Abadi et al. (4), has been primarily applied to study the correctness 



of abstract machines for programming languages (whose semantics 
rely on substitution as a rather inefficient meta-operation), and in 
proof environments. It also appears in the applied pi calculus ]5) to 
facilitate an elegant formulation of indistinguishability for security 
analysis. However, we seem to be the first to use explicit substitu- 
tions to track explicit flows in a concurrent language. Previously, 
dependency analysis (35 . 6 1 has been applied to information-flow 
analysis t2l 1411 l55l . These analyses track stronger dependencies 
than those induced by explicit flows; in particular, the dependen- 
cies are sensitive to control flows. In contrast, the use of explicit 
substitutions to track explicit flows seems rather obvious and ap- 
propriate in hindsight. We believe that this technique should be 
useful in other contexts as well. 

Our analysis manifests a genuine interplay between static typ- 
ing and dynamic access control for runtime protection. We seem to 
be the first to study this interaction in a concurrent system with dy- 
namic labels for multi-level integrity. This approach of combining 
static and dynamic protection mechanisms is reflected in previous 
work, e.g., on typing for noninterference in a Java-like language 
with stack inspection and other extensions (8] 1401 . for noninter- 
ference in lambda calculi with runtime principals and dynamic la- 
bels 1481 1591 . and for secrecy in concurrent storage calculi with 
discretionary access control mechanisms 1141 1131 . A verification 
technique based on this approach is developed by Flanagan 1211 
for a lambda calculus with arbitrary base refinement types. In these 
studies and ours, dynamic checks complement static analysis where 
possible or as required, so that safety violations that are not caught 
statically are always caught at runtime. Moreover, static typing 
sometimes subsumes certain dynamic checks (as in our analysis), 
suggesting sound runtime optimizations. This approach is reflected 
in previous work on static access control l28[|42| [30l . 

In most real-world systems, striking the right balance between 
security and practice is a delicate task that is never far from con- 
troversy. It is reassuring to discover that perhaps, such a balance 
can be enforced formally in a contemporary operating system, and 
possibly improved in future ones. 
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Appendix 

In this appendix, we provide some additional material that may 
benefit the reader. First, we detail proofs of our results on typing 
(AppendixfA}. Next, we outline an efficient typechecking algorithm 
(Appendix IB!. 

A. Proofs 

In this section we outline proofs of the results in Section[5] 

Restatement of Proposition 15.21 (Adversary completeness) Let Y 
be any typing environment and e be any C-adversary such that 
fv(e) C dom(r). Then Y I — r e : .despite C. 

Proof. We prove typability by induction on the structure of pro- 
cesses. 

• e = x where u is a variable. 

Then x £ dom(r). 

By (Typ value) rh c i :.. 

• e = new(x # S). 

By I.H. r r- c x : r E 

Then S C C C 1 C E. 

By (Typ new) Y h c new(x # S) : _ 

• e = <0) to. 

By I.H. r r- c u : - 

So by (Typ value) lu :t e eY. 

Case *E and r is not of the form Obj(_). 

By (Typ bogus stuck-I) Y h c (0) uj : .. 
Case *E, r = Obj(_ s ), and C c S U 0. 

By (Typ un/protect stuck) Y h c (0) w : .. 
Case *E, r = Obj(_ s ), and _L C S U C C = _L. 

Then SCO. 

By (Typ value) and (Typ un/protect) 

T h c (0) lj : .. 



Case E = J_. 

By (Typ subsumption _L-II) 

r = Obj(_ s ) such that SCO. 
By (Typ value) and (Typ un/protect) 

r h c (O) u : .. 



By I.H. r he u : .. 

So by (Typ value) u : r E G I\ 

Case *E and r is not of the form Obj(_). 

By (Typ bogus stuck-I) T h c !w : _. 
Case *E and r = Obj(_). 

By (Typ read) T h c \uj : _ 
Case E = _L. 

By (Typ subsumption _L-II) r = Obj (_ 

By (Typ read) T h c \u : - 



By I.H. r h c w : . and T h c a: : rf . 

So by (Typ value) oj : r E G I\ 

Case *E and r is not of the form Obj(_). 

By (Typ bogus stuck-I) r he w '■= x : _. 
Case *E, t = Obj(. s ), and C c S. 

By (Typ write stuck) r he oj := a; : _. 
Case *E, r = Obj(7i S ), and _L C S C C = _L. 

ThenS C E'. 

By (Typ value) and (Typ write) r he cv ■= x 
Case E = _L. 

By (Typ subsumption _L-II) 

r = Obj(T! S ) such that S C E'. 
By (Typ value) and (Typ write) r he w := x 



• e : 



pack(/). 



By I.H. r h c / : T. 

By (Typ pack) T h c pack(/) 



By I.H. r h c u : so by (Typ value) u : r E G T. 
Case *E and r is not of the form Obj(_). 

By (Typ bogus stuck-I) r he exec to : _. 
Case t = Obj(r! S ), *E, 

and n is not of the form V_. Bin(_). 
By (Typ bogus stuck-II) T he exec u> : _. 
Case t = Obj(ri), *E, and n = Vp. Bin(_). 
Then C = lCPnS. 
By (Typ execute) T he exec uj : _. 
Case E = _L. 

By (Typ subsumption L-U) 
t = Obj(T! S ) and t x = V P . Bin(_) 
such that C = lCPnS. 
By (Typ execute) T he exec uj : _. 
Case *E, r = Obj(rf ), and S = _L. 
By (Typ subsumption _L-I) 

n = V P . Bin(.) such that C = 1 C P n S. 
By (Typ execute) T he exec w : _. 

• e = [P] a. 
If P □ C then by (Typ escalate) T h c [P] a : .. 



Otherwise by I.H. r h P a : _. 
By (Typ limit) F h c [P] a : .. 

• e = let x = a in b. 

By I.H. r h c a : T 

and F, a; : T he 6 : T'. 
By (Typ evaluate) F he let x — a in & : 

• e = a f b. 

By I.H. T h c a : . 

and r h c b : T. 
By (Typ fork) r h c a (* 6 : _. 



Restatement of Proposition l5.3l (Monotonicitv) The following typ- 
ing rule is admissible. 

T h P , / : r E □/ PC P' 

i_ 7 EnP 
T hp / : r 

Proof. We proceed by induction on the structure of derivations. 
Suppose that P' C P. 
Case (Typ variable) 

i:r E er 



rhpi:T 
EnP' 



By (Typ value) F \- P x : t 
Here EnP'^EnPnP'. 

Case (Typ new) 

rh P i:r E SCE 
Thp new(x-#S) : Obj(r S ) P 

By I.H. T hp/ x : r Enp ' 
ThenS C En P'. 

By (Typ new) F h P - new(x # S) : Obj(r s ) p ' . 
Here P' = Pn P'. 



Case (Typ fork) 



Let T = t 



F hp a 



T hp b : T 



F hp a r & : T 



By I.H. T hp/ a : _ and T h P / fe : r 
By (Typ fork) r h P / a r* 6 : r 



EnP' 



EnP' 



Case (Typ store) 

: Obj(r S )-,x : r E } C T SCOnE 
1 hp u h> I : . 

By (Typ store) rhp.wHi: _ p '. 
Here P' = P n P'. 

Case (Typ un/protect) 

r hp u : Obj(r S ) E SCO r— -i 

*p *E 

T hp (O) w : Unit P 1 1 



By I.H. T hp/ to : Obj(r s ) Enp ' 

and if *P' then *P, then *E, and then *(E n P'). 

By (Typ un/protect) V h P / (0) w : Unit p '. 

Case (Typ write) 

Thpio: Obj(r s ) E rh P i:r E ' S C E' i 

- *p *E 

r hp u) := x : Unit 

By I.H. r hp, to : Obj(r s ) Enp ' and F h P , x : r E ' np ' 
and if *\J r then *P, then *E, and then *(E n P') 
and SnP'CE'n P'. 
If S C P' thenS CE'n P'. 

By (Typ write) F h P , lu := x : Unit p '. 
Otherwise P' C S, so that *S. 

Because S C E' C P, we have *P and thus *E. 

By (Typ value) uj : Obj(r s ) E " G F and E C E". 

Then *E". 

By (Typ write stuck) F h P cu := x : Stuck. 

By (Typ subsumption stuck-II) r h P to := x : Unit p . 



Case (Typ execute) 



Obj((Vp". Bin(r E ')) s ) E G F P C P" n S 



n i E'nP 
I hp exec uj : r 

P' □ P C P" n S 
and if *Lj. then *P, and then *E. 
By (Typ execute) F h P / exec ui : r 
Here E' n P' = E' n P n P'. 

Case (Typ read) 

lo : Obj(r S ) E G F 



E'nP' 



r h P \u) : T 



*(S n p) *e 



If *(S n P') then *(S n P), and then *E. 
By (Typ read) F h P / !w : r Snp '. 
Here S n P' = Sn P n P'. 



Case (Typ limit) 



T h P // a : T 
F hp [P"] a : T 



LetT = r h . 
Then E C P". 
If P" C P' then 

E n P' = E. 

By (Typ limit) T h P / [P"] a : r Enp '. 
Otherwise P' C P". 

By (Typ escalate stuck) F h P / [P"] a : Stuck. 

By (Typ subsumption stuck-II) F h P / [P"] a : r Enp ' 

Case (Typ evaluate) 



r hp a : T' T,a;:r'hp&:r 
T hp let x = a in b : T 



Let T = r b . 

By I.H. T hp/ a : T" and F, a; : T" h P / 6 : r 
By (Typ evaluate) F h P / let x = a in b : r 



Enp' 



Enp' 



Case (Typ substitute) 

r hp/ : T' F,x : T' h P a : T 
r hp (wTaiQP 7 ) a : r 



Let T = r E . 

By I.H. T, x : T h P / a : r Enp '. 

By (Typ substitute) Fh P / (ux/fx@P') a : r Enp '. 

Lemma A.l (Bind). Suppose that a = a'{x/y}. Then F hp a 
if and only ifF h P (vx/y@P) a'. 

Proof. By induction on the structure of a' . 



Restatement of Theorem 15.41 (Type preservation) Suppose that 
F hp a and F hp a : _ Then 

1. If a = b then F h P b : .. 



2. If a 



b then F h P b : 



Proof of (1). We prove preservation under = by induction on the 
structure of derivations. 



•L; CT 

let x = £l-ct in b 

£ L ;^b 

a r* ^li/t 

[L'] f L / ;CT (L' C L) 



Case (Struct substitution) 



evaluation context 
hole 

evaluate sequential 
fork child 
fork parent 
restrict substitution 
lower process label 



x i fv(£ LiCT ) U bv(£" L ; ff ) f v(p) n bv(£: L;CT ) = 

(VX//J,@L") 4,{ I /p§L"}U ( rHL';a' = £ L - a \(uX / ^@\J') ajy 

Let a" = {x/p@L"} Ucr. 

• (i/x//i@L") let ?/ = £ L;CT // [o'] L , io ./ in b' 

= let 7/ = fLi(r|[(i / a;/M@L") o'Il'jct' in 6' 
and T' h L (vx/p@L") let y = £ L . a „ [a'] u . al in 6' : T. 

By (Typ substitute) and (Typ evaluate) 

T' h L // n : T" 

wAF',x:T" h L £ L . a ula'\ L ,. a , : T'" 

wdF',x : T",y: T'" h L b' : T. 
By (Typ substitute) and S.R. 

r' h L (vx/p@L")£ L . a ,4a%,. a , :T'" 

andr',y : T'" h L b' : T. 
By I.H. r' h L S L .A(ux/fi&L") a%,. a , : T'" . 
By (Typ evaluate) 

T' h L let y = £ Ua l( V x/fj,@L") a'] L /. CT / in b' : T. 

. (i/x/A»OL")£L i< ,«[a , lL' S a' I* b' 

= £ L;ir l(vx/fji@L")a']L, ;a > r b' 
andT' h L (z/a5//i@L") f L;CT ''[o'lL' ; a' ? b' : T. 

By (Typ substitute) and (Typ fork) 

r' h L // ju : T" 

mdF',x:T" h L £ Li<J « [a'] L , :ff , : T'" 

andT',1 : T" h L b' : T. 
By (Typ substitute) and S.R. 

T' h L {vx/p®L")£ L . a „la'\ L ,, a , :T'" 

and T' h L b' : T. 
By I.H. r' h L £lA(^/p@\-") a'jy. ia , : T'" . 
By (Typ fork) 

r' h L £ UcT {{vx/ti@L") a\,, a , f b' : T. 



. ( w /M@L")6'^L iCT "K]LV 

= b' f £ L;a l(ux/tj,@L")a'} u . !a , 
and T' h L (vx/n@L") b' f £ L;<T "[a'] L / ;(T / : T. 

By (Typ substitute) and (Typ fork) 

andr',x:T" HlV-Hlv :T 
and r',x : T" h L 6' : T'" . 
By (Typ substitute) and S.R. 

V H (^/ M @L")£ L;ct »K]l' ;ct ' :T 

andT' h L b' : T'". 
By I.H. T' h L £l.,*1(vx/h®L") a'\ L ,., a , : T. 
By (Typ fork) 

T' K b' [♦ fi.i4(fx/A*®L") a'l L / ;CT . : T. 

. (i/x//i©L") (i/2//M , @L , ")£ L;CT »I«']L'; t r' 

= (^//x'@L'") f L ;4(^/M@L") a%., a , 
andT' H (i/x/pQL") (yy///m/") S L . a „ {a'\y, al : T. 

By (Typ substitute) and (Typ substitute) 

r' K" /i : r" 

andT', a; : T" h L /» u : T"" 
and V',x :T",y : T'" h L £ L . CT „ [ a '] L ,.„, : T. 
By (Typ substitute) and S.R. 
V',,y: V" h L „ u : T" 
and T' h L /« a*' : T'" 

and r', y : T"", sr : T" h L £ L . a „ [a'] L , i(T , : T. 
By (Typ substitute) 

r'.y : T'" h L (i/as/^QL") ^'Kkv' : T. 
By I.H. r',j/ : T'" h L £ L; 4Wm@L") a'] LV ' : T. 
By (Typ substitute) 

T' k {vy/n'QL'") Sua[{ux/n&L n ) a'\ v , a , : T. 

. (i/x / f/,@L") [L'"] ^ ;CT 4a'l uv , 

= [L'"] ^^[(ra/MSL'Ofl'l-y 
andT' I-l (vx/fj,@L") [L'"] £ U '» ;CT " K1l>< : T. 

By (Typ substitute) and (Typ limit) 

r' h L » /Lt : T" 

and]?', a; : T" h L /» £ L '"ja" Kkv' : 
By (Typ substitute) 

T' h L „, (vx/ t i@L")£ L ,,, :a la'} U:a , :T. 
By I.H. r' hyn £\_m w \(vx/ ijl@L") oIlv = T. 
By (Typ limit) 

r' h L [L'"] f L - ; 4(^/ M @L") a'] L> , : r. 

Case (Struct fork) 

fv(o) n bv(f L;CT ) = 

• a" r let x = £ L ;4a'] L in 6' 

= let as = £ L ;4o" [* o'] L in b' 
and T' I-l a" ? 'let as = f L ;4a'] L in 6' : T. 

By (Typ fork) and (Typ evaluate) 

T' h L a" : T" 

andT' HSl-Ac-'V ■ T'" 

andT',3; : T'" h L b' : T. 
By (Typ fork) 

r' h L a" I* £^[4 : T'" 

andT',2: : T'" h L 6' : T. 
By I.H. r' h L f Li 4o" l» a% : T'". 
By (Typ evaluate) 

T' h L let x = £ L -Ja" [» o'Il in 6' : T. 



• a" I* £ L :4o'1l I* 

= f L; 4a" I* o'Il I* &' 
andT' h L a" [* £ L -4a'] L C b' : T. 



By (Typ fork) and (Typ fork) 

T' h L a" : T" 

andT' H £ L ;4a'lL : r "' 

and r' I-l 6' : T. 
By (Typ fork) 

T' h L a"? £ L .Aa'} L :T"' 

and T' I-l b' : T. 
By I.H. r' h L £ u „la" l» a'] L : T'". 
By (Typ fork) 

r' h L f L; 4a" l* a'l L I* 6' : T. 

• a" r b' [» £ L; 4a'J L 

= 6' r f L; 4a" I* a'] L 
andT' I-l a" [♦ 6' f* Sl^KUl : T. 



By (Typ fork) and (Typ fork) 

V k a" : T" 
and r' K b' : T'" 
andT' KfL^ML : T. 
By (Typ fork) 

r' h L 6' : r'" 

andT I-l a" I* £ L -4a'l L : T. 
By I.H. T' K£ L; 4a" 1* a'] L : T. 
By (Typ fork) 

r' h L 6' [♦ £- L; 4a" [» o'Il : T. 

a" f (ux/fi@L') £L:4a% 

= (ux/u@\J) f L; 4a" r o'Jl 
andT' I-l a" [♦ (i/ar/«@L') £ l -4o'Il : T 



By (Typ fork) and (Typ substitute) 

I \-\_ a : 1 

andT' h L /. CT / ^ : T 

andT',2: :'t"' H f L ;4a'] L : I 7 . 
By S.R. T',x : T'" h L a" : T". 
By (Typ fork) 

r',x:T'" h L a" C £ L; 4a'] L : T. 
By I.H. r', x : T'" K£ L;J [a" I* a'] L : T. 
By (Typ substitute) 

r' h L (vx/u@i') £ L A a " i* a 'k : r. 



Case (Struct store) 

(jj i— > u r* [L'] a = [L'] (w i— > 

L" 

oj^uf [L ] a 

= [L'] ( W H M f a') 
and r' h L uj ^ u I* [L'] a : T. 

By (Typ fork) 

r' \~i ui i— > u : _ 
and T' I-l [L'] a' : T. 
By (Typ limit) 

r' I~l' uj I— > u : _ 
and T' I-l- a' : T. 

By (Typ fork) r' h L / ui ^ u f a' : T. 

By (Typ limit) T' h L [L'] u & u f a : T. 



Case (Stru ct bi nd) 
By Lemma lATI 

Proof of (2). We prove preservation under 
structure of derivations. 



by induction on the 



Case (Reduct evaluate) 

let x = u in a 
r h u let x = u in a' : T. 



(i/x/u@L) a 



By (Typ evaluate) 

rh L «: T" 
and r, x : T" h L a' : T. 
By (Typ substitute) T h L (yx/u@\-) a : T. 

Case (Reduct new) 

new(x # S) — > (f£j/new(x # S)@P) (w £ x [* w) 
T hp new(x#S) : T. 

By (Typ new) 

rhpi: r E , 
SCE, 

andT = Obj(r s ) p . 
By (Typ store) r, u : T h P u h> a; : _. 
By (Typ fork) r, w : T h P w A x I* w : T. 
By (Typ substitute) 



T hp (vw/i\&n(x # S)®P) (w 
Case (Reduct read) 



irw):T. 



L ^ i / L';er L ^ 

LU I — ► x r !cj > W HIT I 

r hL W ^> x [* !w' : r E . 

By (Typ fork) 

ru o 

1 hL o-> > x : _. 

By (Typ store) T h L x : .. 

By (Typ fork) r h L (J A x [♦ x : _. 

Case (Reduct write) 

CT / ■ I — I / 

OJ = W LLL 



wHir u := a; — 
r K w A ar I* := z' : Unit 1 . 

By (Typ fork) 

r u 

1 hL a; i— s- x : _ 

and T h L lo' := x' : Unit 1 

and OCL 

By (Typ store), (Typ write), and r h a 
w : Obj(r s )" G T, 
SCO, 

r h L w' : Obj(r s ) E , 
T h L x' : r E ', 
and S E E'. 

By (Typ store) r h L w A x' : .. 



x' r* unit 



By (Typ unit) r h L tu A unit : Unit 1 . 

By (Typ fork) rh L uHi7 unit : Unit 1 . 



Case (Reduct execute) 



pack(/) £ a(x) 



L" = L' n L 



L rt 

hit exec w 



> oj i— > x r [L J / 



r hL W i— ► x f* exec w' : _. 

By (Typ fork) 

p i o 

1 hL lj >—> x : _ 

and r hL exec a/ : _. 

By (Typ store), (Typ execute), and T h a 

T hp/ pack(/) : V P . Bin(T) p ' for some P', 

x : V P . Bin(T) E € Y, 

w : Obj(V P . Bin(T) s )- G T, 

S E n E, 

and L C P n S. 

By (Typ pack) T h P / : .. 

By (Typ subsumption process label) Y K f : 

By (Typ fork) r h L lu A x [* / : _. 

Case (Reduct un/protect) 

u> = uj LULCL 



L";<r L' rt 

— > w i— > x r unit 



wiiP {!_') a/ 
r h L w A x r (L') w' : Unit L 

By (Typ fork) 

1 hL W I— > x : _ 

andT h L (L') J : Unit 1 

OUL'CL 



By (Typ store), (Typ un/protect), and Y h a, 



Obj(7 



e r, 



SCO, 
r h L u' : Obj(r s )-, 
andS C L'. 

By (Typ store) rh L WHi:.. 
By (Typ unit) F h L unit : Unit 1 . 

By (Typ fork) r h L u & x f unit : Unit 1 . 
Case (Reduct context) 

a > o 



£L;<rMLV' 

£l ; <t ::= 

•L;a 

let x = £l <t in 6 

£ U o I* & 

a r* £l;<7 

(vx/lJ,@\-') £ L ,{x/^U}Uo 

[L'] f LV (L' C L) 



evaluation context 
hole 

evaluate sequential 
fork child 
fork parent 
restrict substitution 
lower process label 



• let X = £\_;<r\a'\v ;a> in 6' — > let X = fL;cr[o"lL';o-' ' n &'> 



/ L';<r' 

a — > a 



and T K let x = Sl^KIlV in b' : T. 
By (Reduct context) and (Typ evaluate) 

rh L £ L;(T [ a '] L , ;CT , :T", 
and T, x : T" h L 6' : T. 

ByI.H.rK£ L ;4a"]LV' : T". 
By (Typ evaluate) 

T h L letaj = £L-A a "h;v> in b ' : T - 

a' L ' ;tT >' a" 

andTHsUMiV' ? b' : T. 
By (Reduct context) and (Typ fork) 

r h L £ L ;a[a'] L> - : T", 
and r h L 6' : T. 

BylErK£U[o'ly : T " 
By (Typ fork) 

T\- L £uJa"]y. a > fb':T. 



a' L ' i<T ' a" 

andrh L 6'V £LiaM L ' iff ' -T. 

By (Reduct context) and (Typ fork) 

£\-A a %';<r' £lA a "it-';<r' < 
r h L f L; 4«'] LV : T, 
andT h L 6' : T". 

ByLH.rhLf Li aIo"]LV :T. 
By (Typ fork) 

rK 6'r £ u Aa"\y, a , :T. 



Case (Reduct congruence) 



{vx/u@L") £lAAl';o 



{ux/u@L")£ L Aa"\i 



a > a 



andT h L (^/M@L") 5 L ;a[o'] L '; CT ' ! T. 

By (Reduct context) and (Typ substitute) 

and r h L " it : T", 

andr,x:T" h L f^Kli-V : T. 
ByI.H.r,x:T" h L £ L Aa'%>;*> -T. 
By (Typ substitute) 

rK (ux/u@L")£ L Aa"j u . tT , :T. 



I L;o- / 

a ► o 



l ;ct 
a > o 



r K a : T, 
a = a , 

l L;o- , 

a > o , 

and b' = b. 

By Theorem|54ll) T \- L a' : . 

By I.H. r K b' : .. 

So by Theorem^!) r h L b : 



Restatement of Theorem 15.71 (Enforcement of strong DFI) Let Q 
be the set of objects whose contents are trusted beyond L in T. 
Suppose that Y I — r a '■ - despite C, where C C L. Then a protects 
flfrom L despite C. 

Proof. Let e be any C-adversary [C] e'. 
By Proposition l5,2i r I — r e : _. 
By (Typ fork) r h T a f e :. .. 

Suppose that w £ fi. We need to prove that there are no a and 

x such that a p* [C] e' — ^* £t:0[I^ ^ k]t ;ct and iTL Assume 
otherwise. 

By Theorem l5.4l there exists V extending F such that 

r'hfrandr'hTWHi;: .. 
By (Typ store) w : Obj(r s )- e T' such that S C E. 
We proceed by induction on the derivation of a; T L. 

Case PCI 

For some r and E, r' hp p, : r E . 

Then E C P and by (Typ value) r' I — r a; : r E . 

Then ECL 

Then S C L. 

But by assumptions S □ L (contradiction). 

Case /i = y for some y and j/ T L. 

By I.H. r'l-Tj: r E for some E such that E C L. 
Then S C L. 

But by assumptions S □ L (contradiction). 

Restatement of Theorem 15.81 (Redundancy of execution control) 

o 



Suppose that T I — r a : _ despite C and a — ^* £t ; 0[w 
exec a/Jp. CT such that it) = it}', and P □ C. Then P CO. 



x r 



[L"]£ L 'v[a']LV ^ [L"]£l» ;ct K1 l / 

/ L ';°"' // 
a > a , 

andrh L [L"l Sy,. Ja'ju^ ■ T. 



By (Reduct context) and (Typ limit) 

£u'-Aa!\ L i. a i L -^> £ L "A a "l\-';<?' 

andrh L » £ v ,AAv;°> -- T - 
ByI.H.rh L » £ L » ;CT [a"] L ' ;CT ' : T. 
By (Typ limit) 

rh [L"] £u'Aa"lu;*> -T- 



Proof. The proof is by inspection of Case (Reduct execute) in the 
proof of Theorem 15.41 Recalling that case (where L is the process 
label): L C S C 0. < 

B. An efficient typechecking algorithm 

Finally, we outline an efficient algorithm to mechanize typecheck- 
ing. Broadly, the algorithm builds constraints and then checks 
whether those constraints are satisfiable. The only complication 
is due to pack processes, which require a "most general" type. We 
extend the grammar of types with type variables \, and introduce 
a distinguished label ? denoting an "unknown" label. We extend 
the grammar of typing environments with constraints of the form 
ri <: T2 and label constraints (i.e., boolean formulae over atoms of 
the form Li C. L2). Next, we introduce the following typechecking 
judgments: 



Typechecking judgments for processes T h P a : T > r' 



Typechecking judgments for expressions r h / : T E> r' 



(Type value) 



(Type new) 



(Type pack) 



x : t e r 



1 hp X : T D> 



r hp u : T > : 



T hp new(it#S) : Obj(r ) H > 



r h / : t > r' r' |= p' □/ 

r hp pack(/) : X P > I^p,, V P , . Bin(T) <: X 



(Type fork) 



rh P a:_l>ri r\- P b:Tr>T; 
r hp a r 6 : To Ti,r 2 



(Type evaluate) 

r hp a : T' l> Ti r,ri,x : T' hp 6 : T> T 2 



(Type read) 



T hp let x = a in b : T> T 1 ,T 2 



u : Obj(r S ) E £ T 

T hp \lu : r SnP > 



(Type write) 



rhpu: Obj(ri) E r h P u : r 2 

r hp lj := w : Obj(r S ) E E> t 2 <: Ti 



(Type execute) 



w : Obj(r 1 s ) E , V P /. Bin(r E ') <: n € T 

■n i E'nP ^ , v-7 -I-,. / P'nP\ 

1 hp exec lu : r D> Ti <: Vp. Bin(r ) 



• r hp a : T > r', where T' contains constraints of the form 
Ti <: T 2 only (i.e., the label constraint in T' is true). 

• r h / : T > r', where T' may contain a label constraint as well 
as constraints of the form ti < : r 2 . 

We now present some sample typechecking rules, followed by rules 
that interpret < : . Let us first look at the rules for deriving judgments 
of the form V hp a : T t> V' . These rules build constraints of 
the form n <: r 2 in V' . We elide by dots (...) label constraints 
that appear in the original typing rules. Let r', ML denote the typing 
environment obtained from Y 1 by replacing all occurrences of ? 
with L. We write T' |= P iff P is the highest L for which the label 
constraint in r',^ L is true. Note that to derive a judgment of this 
form for a process pack(/), we need to derive a judgment of the 
other form for /. In fact, the two kinds of judgments are mutually 
recursive (see below). 

Next, we look at the rules for deriving judgments of the form 
r h / : T D> r'. These rules apply to expressions that are not 
explicitly under a change of the process label, e.g., expressions 
obtained by unpacking pack processes. They build label constraints 
from those that appear in the original typing rules; the implicit 
(unknown) process label is replaced by ?. Predicate □ ensures that 



x : t G r 
fhi: r En? > . 



rW' hp/ a : T > r' 
T h [P'] a : T > r' 



lu : Obj(Y s ) E £ T 
r h !w : r Sn? r> ... 



(Type ? value) 



(Type ? limit) 



(Type ? read) 



(Type ? write) 

rhu: Obj(ri) E Fhu: t 2 E ' 
r h lj := u : Obj(r S ) E E> r 2 <: Ti, .. . 

(Type ? execute) 

lu : Obj(r 1 s ) E , V P /. Bin(r E ') <: n € T 

T-i I E'n? . . v7 T3- i P'n?N 

1 h exec lu : r > Ti <: V?. Bin(r ), ■ ■ ■ 

(Type ? fork) 

Tha:_I>ri rhb:Tl>r2 

rh/rs :T>ri,r 2 

(Type ? evaluate) 

r h a : T' t> Ti r, Ti, x : T' h b : T > T 2 
r h let x = / in g : T \> T 1 ,F 2 



Satisfiability of constraints fho 



(Type <: obj) 



(Type <: bin) 



rho 



r,Obj(T)<:Obj(T)ho 



P ; CP r,ri<:r 2 ho 
T, V P . Bin(r E ) <: V P /. Bin(r 2 EnP ') h o 

(Type <: left) 

T,x <: Vp. Bin(r 1 E ), Vp. Bin(T E ) <: V P /. Bin(r 2 E ') h o 
r, X <■ Vp. Bin(r E ),x <: V P /. Bin(r 2 E ') h o 

(Type <: right) 

r,V P . Bin(ri E ) <: V P /. Bin(r 2 E '), V P /. Bin(r 2 E ') <: X h o 
r,V P .Bin(r E ) <: X ,Vp/.Bin(r 2 E ') <: X h<> 

(Type <: middle) 

T, V P . Bin(r E ) <: X , X <: V P /. Bin(r 2 E ') % 

Vp. Bin(r! E ) <: V P /. Bin(r 2 E ') h o 
T, V P . Bin(r E ) <: X ,X <: V P /. Bin(r|') h o 



we do not need to consider pack processes here; further we can 
assume that all annotations carry the least trusted label. Once we 
have an expression of the form [P] a, we can derive a judgment of 
the other form for a. 

Finally, we look at the rules that interpret constraints of the form 
T\ <: T2- Here <: denotes a subtyping relation that is invariant in 
Obj(_ s ) and covariant in Vp. Bin(_ E ), and preserves monotonic- 
ity. We introduce the judgment T h o to check satisfiability of such 
constraints. 

We prove that typechecking is sound and complete. 

Proposition B.l. The typing judgment T hp a : _ can be derived 
if and only if the typechecking judgment T hp a : T E> T can be 
derived for some T and T such that r ho. 

Further, typechecking terminates in time C(L|a|)) if F and a have 
L distinct labels. Indeed, let ^(M) be the running time of the 
judgment T hp a : _ E> _, and ip(\f\) be the total running time 
of the judgments rh/:.>F and T' |= _ for some T' . 

Building constraints for the typechecking judgment T I — r a : 
ToF takes time 

V(|a|) = 0(|a| + E (€ i.. n tf(|/ I |)) 

if a contains as subterms the processes pack(/i), . . . , pack(/„) 
without nesting. Checking the satisfiability of those constraints 
reduces to detecting cycles in a graph, and takes time 0(\a\)), so 
the total running time for typechecking is 

$(M) = p(|o|) + 0(|o|) 

= OQa\ + £ i6 i..„V(|/i|)) 
Next, building the label constraint for the typechecking judgment 
F h fi : T > T' takes time OQfi\ + T, je i..mMHi\)) if 
fi contains as subterms the processes [Pa] a' n , . . . , [PimJ a' im . 
without nesting. Finding L such that r' |= L takes time 0(L|/i|)), 
since at most O(L) labels need to be checked. So 

Wil) = o(\f i \ + -£ jel .. m MWiA)) + o(Mf i \) 

= 0(h\fi\+^ jel .. m M\aij\)) 
Plugging the expansion of ip into the expansion of $, and solving 
by induction: 

$(|a|) = 0(\a\ + T, iel ..„L\fi\ + 'Siei..njei..m t 'fi(\aij\)) 
= 0(h\a\) 



